Starflight Instances

All object instances in Starflight are stored in a file named INSTANCE located on STARB.COM:

  i  NAME         TYPE  START   END     #REC    RLEN  SLEN
  1  INSTANCE        2  0x3f80  0x643f  0x24c0  0x10  0x00

This file contains objects that are created before the game starts. From the moment the game starts until it ends, objects are
created and destroyed continuously. The three level object hierarchy is stored as follows:

  • Class: each class has a file entry in the directory. This entry may be virtual or may point to a real class file.
  • Species: the class file, if present, has #REC records of length RLEN. Each record defines a species of this class. A record is a set of species attributes, each one storing a value like name, mass, volume, etc.
  • Instance: a species can have zero or more object instances. All object instances, no matter from which class or species, are stored together in the INSTANCE file. This file is 150528 bytes long and have variable-length records, each record corresponding to an object instance. The INSTANCE file is structured as a tree, where each node is an object instance. A node can have zero or more siblings and zero or more children. In this way objects can be contained inside other objects (example: a PLANET inside a STARSYSTEM).

Each record inside INSTANCE has a fixed-length part and a variable-length part. The fixed-length part is always 11 bytes long and
stores information about class/species and for navigating the object tree:

  • Next sibling: 3 bytes. Pointer to the INSTANCE record of the next sibling. A 3-byte pointer can address up to 16777216 bytes, which is more than enough to address the 150528 bytes of the INSTANCE file.
  • Previous sibling: 3 bytes. Pointer to the INSTANCE record of the previous sibling. The sibling list is circular, so the last sibling is actually a pointer to the first sibling.
  • First child: 3 bytes. Pointer to the INSTANCE record of the first child, or 0 if the instance does not have children.
  • Class: 1 byte. Contains the class number of this instance, which is also the directory index of the class.
  • Species: 1 byte. Contains the species number of this instance, which is also the record index of the species inside the class file. However, in some instances this field may be used for other purposes than to store the species number.

The variable-length part is SLEN bytes long, storing the instance attributes (SLEN varies from class to class, and can be zero). Take for example the ARTIFACT class:

  i  NAME         TYPE  START   END     #REC    RLEN  SLEN
 28  ARTIFACT        2  0x652c  0x658e  0x0034  0x1e  0x06

There are 52 (0×34) species in class ARTIFACT. A record in the ARTIFACT file containing the species fields has 30 (0x1e) bytes and the
variable-length part of the record inside INSTANCE has 6 bytes. The instance record total size is then 11+6 = 17 bytes.

I have decoded most of the INSTANCE file and the result can be found here. This file contains the whole object tree in text form. The root node is an instance of IROOT and is located at offset 6. For classes for which I have not decoded its attributes only the name is shown. As an example consider this excerpt:

        STARSYSTEM    F 234,020 10011100 4619-06-15
          PLANET        2 2
          PLANET        2 5
            ARTIFACT      "BLACK EGG..............." 25000 0.1 34.6S 98.9E

The first line is an instance of STARSYSTEM. The attributes are:

  • Star type: F.
  • Starmap coordinates: 234,020.
  • Bitmask defining which of the 8 possible orbits have planets: 10011100 (in this case only orbits 1, 4, 5 and 6).
  • Expected flare date in year-month-day format: 4619-06-15.

The second and third lines are instances of PLANETs contained in this STARSYSTEM. The first number is the planet type and the second
number is the surface type:

Planet type Meaning
1 Planetoid
2 Small planet
3 Earth-like planet
4 Large planet
5 Gas giant
6 Crystal planet
7 Earth
Suface type Meaning
0 Crystal (endurion)
1 Gas
2 Liquid
3 Ice
4 Molten
5 Rock

The fourth line is an instance of ARTIFACT contained in the second PLANET. The attributes are:

  • Name: “BLACK EGG……………”
  • Value: 25000 MU’s
  • Volume: 0.1 cubic meters
  • Latitude: 34.6S
  • Longitude: 98.9E

Other classes are described here:
for RUINs the latitude and longitude are shown. For FLUX-NODEs the origin and destinations coordinates are shown.
For NEBULAs the center and radius (?) are shown. For ELEMENTs the name and value are shown.
A BOX is generic container for other objects and can be named or unnamed.
The number before each STRING defines its type, but all strings in the tree have type 32 (?).

The number after ORIGINATOR identifies a race. The values I have determined so far are:

Originator Meaning
1 Elowan
2 Gazurtoid
3 Mechan 9
4 Mysterions
5 Nomad probe
6 Spemin
7 Thrynn
8 Veloxi
9 ???
10 Veloxi drone
11 Minstrels
16 Humans (your ship)
18 ???
19 ‘Lasthope’ ship recording
21 Interstel police

Inside each ORIGINATOR there is a BOX instance. This BOX contains a series of STRINGs which seem to be the syllabes used to
garble the alien language when your communications officer is not experienced.
The number after SUBJECT identifies the subject of a communication during an encounter. The values I have determined so far are:

Subject Meaning
1 Greeting messages (?)
2 Greeting messages (?)
5 “I do not know” messages
6 Demanding answer
7 Answers: thenselves
8 Answers: other races
9 Answers: general info
10 Answers: old empire
11 Answers: the ancients
13 Statements (?)
14 Initial questions (?)
15 Farewell messages

PHRASECONTRL probably defines when/where a message can be used, but I do not know how its fields are encoded.
The first number after ENCOUNTER identifies the race, according to the originator table. The second value are the coordinates
where the encounter takes place. If an ENCOUNTER is contained in a PLANET, the encounter takes place when orbiting the planet.
The other kinds of encounters are in STARSYSTEMs and in outer space.

Besides storing the object tree starting with IROOT, it seems the INSTANCE file also stores a circular linked
list of STRINGs. Most of these strings do not not appear inside the object tree, so I suspect their
addresses are stored inside the game logic. This list also has some oddities, like some strings apearing twice, and some strings
that may not be used in the game. Different from strings in the main tree, here the type is apparently used to group strings of
related subject:

Type Meaning Example
1 Body parts Leg
2 Behavior Flying
3 Body parts Head
4 Body parts Feet
5 Body parts Hair
7 Color Green
8 Color Black
9 Creature type Carnivore
10 Size Large
11 Shape Flat
13 Appearance Grotesque
32 Anything It is snowing heavily

Leave a Reply

Choose how to leave your comment

To prevent comment spam, you must verify you own your email address using Mozilla Persona (Browserid) by clicking the green Sign In button.